MeeGo : Lead by example

One of MeeGo's biggest failings IMHO is related to its customers.

We expect our customers to work with us and against our systems: OBS, BZ etc - but do we even know how that 'work with us' is supposed to work?

We expect our customers to track bugs in our Bugzilla and link to their private Bugzilla. How exactly?

When a problem is seen in MeeGo we expect a bug report and/or a patch - yet we can't even make that work ourselves; our UX team are granted special rights that customers don't have. Certain patches appear referencing private bug trackers (eg B.O.O bugs) - if Intel can't get this right then our customers have no chance. The only way to solve this problem, and to keep on top of it, is to ensure that significant parts of the MeeGo project act as if they were external customers - still very much a part of the open community but experiencing the social and technical interfaces that we expect customers to use.

I propose we handle this in 2 ways:

• CE, UX and Tools to become discretely scheduled MeeGo Projects
  
• Seperate OBS, BZ and REVS infrastructure for Projects and Core
  (reviewed in more detail later)
  
• No special handling of any Projects (eg UX)
  

A more powerful long term solution is to take the opportunity that the Community Edition project offers to fulfill the role of a 'reference vendor' and openly demonstrate how effectively MeeGo can deliver. We should use this to explain, demonstrate - and validate - how real vendors should interact with the MeeGo project at all levels: features, bugs, processes, release management, communication and even infrastructure.

Essentially we should make "How to be a MeeGo Product Builder" a MeeGo Project deliverable.